The Data-Over-Cable Service Interface Specification (DOCSIS) was established by cable television network operators to facilitate transporting data traffic, primarily Internet traffic, over existing community antenna television (CATV) networks. In addition to transporting data traffic, as well as television content signals over a CATV network, multiple services operators (MSO) also use their CATV network infrastructure for carrying voice, video on demand (VoD) and video conferencing traffic signals, among other types.
The use of IP (Internet Protocol) to transport digital video is moving rapidly from user datagram protocol (UDP) and proprietary transports like Adobe real-time messaging protocol (RTMP) to the progressive download of a series of small files over a hypertext transfer protocol (HTTP) transport. This can be identified as segmented HTTP Transport (SHT). SHTs typically use a construct called a manifest file to tell the client how to request the segments in the appropriate order.
One feature that has been layered on top of SHTs can be identified as adaptive streaming. Rather than just encoding a piece of video for a single quality/bit rate, that piece of video can be encoded for multiple bit rates. In effect systems using this technology produce N versions of the same piece of video, one for each bit rate. In this example, the manifest file construct is extended with information that allows the client to request different bitrates as it adapts to network traffic conditions.
The client can use a variety of algorithms to determine which bitrate it will choose. If operating conditions such as network congestion cause the client to run out of data or the CPU load causes the client to drop video frames, then the client can choose a lower quality version for the next segment in the sequence. Conversely, if the content is arriving quickly, the client can ask for a higher quality version of the next segment.
Another improvement added to adaptive SHTs is live streaming. Live SHTs are similar to on demand SHTs, but include two significant differences: 1) because the content is being encoded in real-time, new segments are being created, so the manifest file is constantly updated; 2) because the content is being produced and consumed at about the same time, the client continues to request updated versions of the manifest file to receive information on how to request the newly added segments of video.
The move to the HTTP transport can provide a number of benefits over proprietary or using a UDP-based transport. For example, HTTP is a standard that is broadly supported by network equipment like routers and CPE. Problems related to network address translation (NAT) that can occur with UDP-based transports are not an issue with HTTP, which is based upon transmission control protocol (TCP). While there are multiple proprietary implementations of SHTs, if the SHTs are well behaved, the content segments can be cached in a traditional edge cache. The use of a content delivery network (CDN), which includes globally distributed edge caches, provides a generic way to provide cost effective scale for content delivery.
In existing implementations, advertising is inserted into the content before the content is encoded. Delivering a customized version of live or stored video content can involve multiple versions of the same content being created. Such implementations can involve encoding and storing the multiple versions of the content individually. In a city like Los Angeles there may be 90 ad zones, which would result in 90 unique instances of the same program. Not only is the encoding and a storage facility costly for this kind of configuration, the benefits of user specific advertising that is expected for internet based technologies are not realized.
One method that has been used to address this operational inefficiency is to have the client device implement the ad splicing function. With this approach the client is notified that the ad is to be inserted into the video content. The client then requests a replacement ad from an ad server and at the appropriate time, stops video play back of the content, plays the replacement ad, and then resumes playback of the video at the appropriate place. This solution is not optimal because there can be significant overhead in starting a second video stream. For example, there can be a long delay for the video player to load up its buffers. It can also be inefficient because two pieces of video content are being downloaded at the same time.
Like reference numbers and designations in the various drawings indicate like elements.